Security News
Opengrep Emerges as Open Source Alternative Amid Semgrep Licensing Controversy
Opengrep forks Semgrep to preserve open source SAST in response to controversial licensing changes.
@stamp/privatize
Advanced tools
Makes all properties and optional methods private
Inspired by the private-class
module. NOTE! Requires WeakMap, thus won't work in IE10.
This stamp (aka behavior) will create a proxy object. Its methods would delegate all the calls to the original object instance.
All the properties are made private. Methods privatization is optional and can be done via the privatizeMethods
static function.
import Privatize from '@stamp/privatize';
import Auth from './stamps/auth';
const AuthWithPrivateProperties = Auth.compose(Privatize);
const AuthWithPrivatePropertiesAndMethod = Auth.compose(Privatize).privatizeMethods('setPassword');
Or if you don't want to import the stamp you can import only the method:
import {privatizeMethods} from '@stamp/privatize';
const AuthWithPrivatePropertiesAndMethod = Auth.compose(privatizeMethods('setPassword'));
Every property you assign in the initializers will be private.
const Original = compose({
initializers: function () {
this.foo = 42; // THIS WILL BE PRIVATE
this.bar = function () {}; // THIS WILL BE PRIVATE TOO
}
});
Original().foo === undefined;
Original().bar === undefined;
This is a neat feature since you don't need to use JS closures to hide variables from external users.
let accessPassword, accessSetPassword;
const Original = compose({
properties: {password: '123'},
methods: {
setPassword(value) { this.password = value; },
checkAccess() {
accessPassword = this.password;
accessSetPassword = this.setPassword;
}
}
});
// Add Privatize behavior, additionally protect the 'setPassword' method
const Stamp = Original.compose(Privatize).privatizeMethods('setPassword');
// All properties and the method 'setPassword' are undefined
const instance = Stamp();
expect(instance.password).toBeUndefined();
expect(instance.setPassword).toBeUndefined();
// But the 'checkAccess' method have access to the properties and 'setPassword'
instance.checkAccess();
expect(accessPassword).toBe('123');
expect(accessSetPassword).toBe(Original.compose.methods.setPassword);
If you ever was thinking how cool if it was having configuration
(and deepConfiguration
) accessible in your method without explicitly exposing it through initializer, with privatize stamp you can simply do this. First make your own extension to Private stamp.
import Privatize from '@stamp/privatize';
const ConfiguredPrivatize = Privatize.compose({
initializers: [(_, {stamp, instance}) => {
instance.stampConfiguration = stamp.compose.configuration;
instance.stampDeepConfiguration = stamp.compose.deepConfiguration;
}]
})
export default ConfiguredPrivatize;
Then you can use for your other stamps and being able to access configuration within any method while still have it hidden from public sight.
compose(ConfiguredPrivatize, {
configuration: {
secret: 'mykey'
},
methods: {
encrypt(value) {
const { secret } = this.stampConfiguration;
// run encryption with secret while it's still hidden from outside
}
}
})
This @stamp/privatize
module knows about and relies on other ecosystem stamps implementation. This means that other @stamp/*
ecosystem stamps should know nothing about @stamp/privatize
. But opposite is acceptable.
FAQs
Protect private properties
We found that @stamp/privatize demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Opengrep forks Semgrep to preserve open source SAST in response to controversial licensing changes.
Security News
Critics call the Node.js EOL CVE a misuse of the system, sparking debate over CVE standards and the growing noise in vulnerability databases.
Security News
cURL and Go security teams are publicly rejecting CVSS as flawed for assessing vulnerabilities and are calling for more accurate, context-aware approaches.